I think I get what the other change is going for, but what is this one doing?

This prevents perfect curve type anchors from losing curve type on undo/redo/reload if the segment has <3 anchors or they are colinear. We already have editor features that prevent you from creating invalid sliders, so its unnecessary to do this in parsing.

We already have editor features that prevent you from creating invalid sliders, so its unnecessary to do this in parsing.

I dunno if I agree with that, people still manually edit beatmaps and will continue to do so regardless of if we want that or not. We need protections against such stuff on decode.

The collinearity check getting skipped is especially alarming to me since its purpose is to prevent circular approximations with arbitrarily large radii, which is generally numerically unstable and can lead to various strange things happening.

I'd want to know which scenarios this "breaks" specifically to make a judgement call on whether this removal is worth the potential tradeoffs.

There are already protections against colinearity in perfect curve sliders built into the path calculation. Its already trivial to make a circular slider with arbitrarily large radii inside the editor, so parsing doesn't seem like the right place for those protections anyways.

The only thing that makes sense to convert in parsing is perfect curve segments with >3 anchors. These are invalid and impossible to make inside the editor.